1. Field of the Invention
The present invention generally relates to workflow processing and, more particularly, to creation and execution of data driven dynamic workflows.
2. Description of the Related Art
Workflow processing technologies typically provide application integration capabilities, enabling a series of separate software components to be run in a defined order facilitating construction of larger solutions from individual software components. Workflow implementations are typically driven from a workflow definition, commonly captured as an eXtensible Markup Language (XML) document, that identifies the order of operations to perform and data flows from one operation to another. Thus, workflow engines provide the ability to string together functionality from different applications and servers into an overriding process, i.e., a workflow.
In recent years, Integrated Development Environments (IDEs), such as Websphere Studio Application Developer Integration Edition (WSAD-IE) available from International Business Machines of Armonk, N.Y., have focused on improving user interfaces for workflow development. Such user interfaces allow users to manipulate and change workflow designs graphically and typically provide drag-and-drop features to simplify workflow development processes. Thus, users without particular programming skills may use such user interfaces to define workflows. However, complexity, performance and scalability of such workflows are generally limited compared to the potential of a workflow designed by a developer with programming skills.
Another drawback of current workflow technology is that a workflow is structurally defined during a development phase within an IDE which results in a static workflow definition. This static workflow definition can then be deployed on a server and is instantiated when used by an executing application, resulting in a unique workflow instance. Because the workflow definition is static, the definition is not amenable to changes after the initial deployment. Accordingly, difficulties arise if a deployed workflow must be changed structurally after the initial deployment or if a new, structurally different workflow is needed in addition to the deployed workflow.
More specifically, if the deployed workflow must be changed structurally after the initial deployment, an entirely new workflow must be defined to replace the original workflow as the definition of the original workflow is static. However, appropriate workflow development skills are required to use a corresponding IDE to define this new workflow. Furthermore, depending on the complexity of the original deployed workflow programming skills may be required to define the new workflow based on the original workflow. Moreover, removing the deployed workflow and deploying the new workflow may require application server skills dependent on the application environment in which the deployed/new workflow should be removed/deployed. On the other hand, if a new, structurally different workflow is needed in addition to the original deployed workflow, an underlying application that is intended to use both workflows needs to be updated to make use of both such workflows. Updating the underlying application requires the skills and knowledge necessary to perform the update. Finally, a currently executing workflow cannot be changed structurally. In this case, execution of the workflow must be terminated and a new, updated workflow must be defined and deployed on a corresponding application server. Subsequently, the work assigned to the original workflow must be sent to the new workflow for completion.
Therefore, there is a need for a more flexible technique for creating and deploying workflows and for managing execution and modification of deployed workflows.